feat(Toast): containerRef and global show option#621
Conversation
0c47393 to
f9775b6
Compare
|
@blvdmitry I'd be happy to see this small feature in the next release. |
|
@malinindev Global is a good improvement. For the container ref - does it cover any additional use cases that nested ToastProviders don't cover today? There is a story with a demo of those |
Actually,
Toasts should always be shown in the Main Area only (we render pdf document there). The other parts have their own specific features, related to the document in Main Area but aren't called inside Main Area. And we cannot move all the functionality into Main Area, because it's used for render a document only. So we have such a layout (roughly): <div>
<ToastProvider>
<Header>
<div>
<Sidebar1 />
<MainArea />
<Sidebar2 />
</div>
<ToastProvider />
</div>
If we call toast from the left sidebar like this And there is no way to do correctly it with the current toast API (I only achieved it in our App with extremely ugly code) But with the new API with containerRef, provided in this PR, we can do just: <div>
<ToastProvider containerRef={mainAreaRef}>
<Header>
<div>
<Sidebar1 />
<MainArea ref={mainAreaRef}/>
<Sidebar2 />
</div>
<ToastProvider />
</div>And all problems will be solved |
|
Also, I was hesitating about I chose toast.show({
global: true,
title: 'halo',
})But another solution could be toast.showGlobal({
title: 'halo',
})Which is preferable here - up to you @blvdmitry |
|
@malinindev so it feels like this example is similar to what you're trying to achieve if you wrap main area with ToastProvider? https://www.reshaped.so/docs/components/toast#render-boundaries |
Not really. If I wrap I need to call I cannot move Here is an example in sandbox: https://codesandbox.io/p/sandbox/bitter-bash-yxf29l If this can be achieved with the standard |



Summary
Two related additions to
<ToastProvider>/useToast, both about decoupling where toasts are rendered from where the provider sits in the React tree:1.
containerRefprop on<ToastProvider>When provided, toast regions are rendered into the referenced DOM element via
ReactDOM.createPortalinstead of inline next tochildren.useToast()consumers see the provider) — still follows the React tree, unchanged.Mirrors the existing
containerRefpattern already used by<Flyout>.2.
globaloption inshowtoast.show({ ..., global: true })renders the toast in the root provider, ignoring any nested provider'scontainerRef. Useful when your whole app is wrapped in acontainerRefprovider but you occasionally need a toast on top of everything (e.g. a critical error), without restructuring the tree.toast.hide(id, { global: true })mirrors it.Screenshots / Recordings
Notes for Reviewers
containerRefis additive (~10 lines inToastProvider.tsx); no changes toToastRegion,useToast, orToast.module.css. The target element must be CSS-positioned (documented in the prop's JSDoc), since the nested region relies onposition: absolute.globalworks by each provider tracking the topmost provider in the chain via context;show/hidedelegate there when the flag is set. Onlyadd/hideare global-aware (the public API) —show/removeare internal lifecycle calls handled by the root region itself.containerRef,global) cover both the visual demo and theplay()assertions.